Call i2c_set_timeout in i2cSetClock #6537
Merged
+2
−0
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Using v2.0.2 on a SparkFun ESP32 Thing Plus to communicate with a u-blox ZED-F9P GNSS module via I2C at 400kHz. The u-blox modules are known to clock-stretch.
I was seeing badness on the I2C bus, which looked very similar to the clock stretching issue from #5875 .
The badness appears when using this code to initialize the Wire bus and change the speed to 400kHz:
The badness goes away when using:
This made me suspect
i2cSetClock
and wonder if it needed the same fix as #5910 .I replicated @me-no-dev 's fix #5910 , calling
i2c_set_timeout
from insidei2cSetClock
. Sure enough, the badness goes away.Impact
This PR prevents I2C badness when using speeds other than the default 100kHz to communicate with devices which clock stretch.
Related links
Related to:
and: